Dell Precision T3600

Einrichtung einer Dell Precision T3600 Workstation unter Linux

Bei ITSCO habe ich mir eine gebrauchte Dell Workstation "Precision T3600" gekauft. Das ist ein sehr gutes, zum Neupreis für mich absolut unbezahlbares Arbeitspferd mit E5-1650 CPU ("Sandy Bridge"), Intel C602 Chipsatz und einer NVidia Quadro 5000 Grafikkarte. Ich möchte hier ein paar Zeilen zur Linux Installation auf diesem Gerät schreiben, da ich ein paar kleine Probleme hatte, die aber alle lösbar sind. Zusammengefasst in einem Satz kann man schreiben das Linux (hier Kubuntu 16.04) sehr gut auf dieser Workstation/PC funktioniert.. Was heißt das konkret: Die eingebaute Hardware ist unterstützt: Grafik, Netzwerk und alle internen Schnittstellen. Es muß nicht gebastelt werden, sondern alles funktioniert out-of-the-box (Stimmt nicht ganz, mehr dazu unten)

Im Dell Precision T3600 eingebaute Hardware

In meiner konkreten Maschine war vorhanden

Den sonst wohl immer verbauten Dell PERC H310 SAS Controller hat entweder der Vorbesitzer oder ITSCO ausgebaut. Das Mainboard hat aber sowieso einen SAS und SATA Controller on-board

Einschub zu Umbauten bis Mai 2023

Mittlerweile ist die Maschine mehrfach von mir umgebaut worden, sie hat jetzt 64 GB ECC REG RAM (4*16GB DDR3-1600 Module), dazu eine NVidia Geforce GTX 1060 Grafikkarte. Um schnellen Plattenplatz zu haben habe ich so eine PCIe zu M.2 Karte und ein nvme Modul von Samsung eingebaut.

Nachdem nun einige Jahre ins Land gegangen sind, ist die Maschine immer noch gut nutzbar, allerdings gibt es eine Sache die nun doch etwas lästig ist: Das BIOS ist sehr zickig mit den Bootlaufwerken - ich habe es neulich (Mai 2023) nicht geschafft einen USB Stick mit ubuntu 22.04 zu starten. Da bin ich wohl von dem in diesem Forenartikel beschriebenen Problem betroffen. Der Versuch "UEFI" Boot zu nutzen kann man sich auch gerade schenken, da dann gerne mal alle Bootmenüeinträge verschwinden, am zuverlässigsten startet die Maschine von einer "klassischen" SSD oder Festplatte vom MBR ("Legacy Boot").

Das "schwierigste hat sich für mich dann als das leichteste herausgestellt: Da ich weder eine brennbare DVD habe, noch irgendwie ein Startfähiges Image auf USB hinbekommen habe, habe ich via PXE Boot gestartet. Das lief dann ganz gut. Das via PXE gebootete System eigenete sich dann auch als "Rettungsssystem" um das NVMe zu löschen (obwohl da nur /home drauf ist, weigert sich mke2fs von ubuntu 22.04 das im laufenden System zu formatieren, obwohl /home ganz normal abgehängt werden konnte (root - login via konsole) ).

Vorhandene PCI Devices (Stark gekürzt, nur die "interessanten"):

00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 05)
00:1a.0 USB controller: Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #2 (rev 05)
00:1b.0 Audio device: Intel Corporation C600/X79 series chipset High Definition Audio Controller (rev 05)
00:1d.0 USB controller: Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #1 (rev 05)
00:1f.2 SATA controller: Intel Corporation C600/X79 series chipset 6-Port SATA AHCI Controller (rev 05)
00:1f.3 SMBus: Intel Corporation C600/X79 series chipset SMBus Host Controller (rev 05)
03:00.0 VGA compatible controller: NVIDIA Corporation GF100GL [Quadro 5000] (rev a3)
03:00.1 Audio device: NVIDIA Corporation GF100 High Definition Audio Controller (rev a1)
05:00.0 Serial Attached SCSI controller: Intel Corporation C602 chipset 4-Port SATA Storage Control Unit (rev 05)
07:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 04)

Jede Menge weiterer PCI Geräte sind noch darüber hinaus zu sehen, davon sind die meisten "System peripheral" Komponenten und Bestandteil der CPU oder des C602 Chipsatzes.

Umbaumaßnahmen für den Heimbetrieb

HDD-Probleme

Danach habe ich das mitgelieferte Windows 7 sich fertig installieren lassen. Das eigentlich nur um zu schauen ob die Maschine den Transport überstanden hat und prinzipiell funktioniert. Nachdem das sichergestellt war habe ich die Bootreihenfolge angepasst und einen USB Stick mit Kubuntu 16.04 gestartet. Hier war schon offensichtlich zu sehen, daß die ganze eingebaute Hardware funktioniert, daher habe ich den Rechner nochmal umgebaut.

Auf der Hauptplatine des Precision T3600 sind 6 "SATA" Buchsen vorhanden. In der Reihenfolge von den Steckkartenplätzen weg eine blaue, 3 schwarze, eine weiße und noch eine schwarze Buchse. Hierbei sind die blaue und die 3 darauf folgenden schwarzen Buchsen je SAS Anschlüsse die vom on-Board SAS Controller bedient werden (PCI-Komponente "05:00.0 Serial Attached SCSI controller: Intel Corporation C602 chipset 4-Port SATA Storage Control Unit (rev 05)"). Dieser Controller wird von Linux vom "isci" Treiber unterstützt. Die weiße und die darauf folgende schwarze Buchse ist mit der PCI Komponente "00:1f.2 SATA controller: Intel Corporation C600/X79 series chipset 6-Port SATA AHCI Controller (rev 05)" verbunden. In der online verfügbaren Boardbeschreibung wird darauf leider nicht näher eingegangen, es wird nur erwähnt daß die blaue Buchse speziell für Platten geeignet ist.

Der Beschreibung folgend habe ich eine schon vorhandene Samsung SSD 840 (Evo) Series an die blaue Buchse und die 1,5 TB Seagate Platte an die darauf folgende Buchse angeschlossen. Die 1,5 TB Seagate Platte habe ich umgesteckt, die war nämlich an der weißen Buche angeschlossen

CRC-Busfehler

Beim Bootup meldet der Linux-Kernel 4.4.0 folgendes über die SSD am SAS Controller

Apr 24 11:42:22 python kernel: [    2.724900] ata7.00: ATA-9: Samsung SSD 840 Series, DXT06B0Q, max UDMA/133
Apr 24 11:42:22 python kernel: [    2.724916] ata7.00: 488397168 sectors, multi 16: LBA48 NCQ (depth 31/32)
Apr 24 11:42:22 python kernel: [    2.725426] ata7.00: configured for UDMA/133
Apr 24 11:42:22 python kernel: [    2.725524] sas: --- Exit sas_scsi_recover_host: busy: 0 failed: 0 tries: 1
Apr 24 11:42:22 python kernel: [    2.740733] scsi 6:0:0:0: Direct-Access     ATA      Samsung SSD 840  6B0Q PQ: 0 ANSI: 5
Apr 24 11:42:22 python kernel: [    2.740932] sas: Enter sas_scsi_recover_host busy: 0 failed: 0

Nach der Installation kam es gelegentlich zu folgendem Fehlerbild im Kernel-Log

Apr 24 14:09:22 python kernel: [  354.760996] ata7.00: exception Emask 0x0 SAct 0x7fc00000 SErr 0x0 action 0x6 frozen
Apr 24 14:09:22 python kernel: [  354.761003] ata7.00: failed command: READ FPDMA QUEUED
Apr 24 14:09:22 python kernel: [  354.761011] ata7.00: cmd 60/80:00:80:fb:c6/00:00:08:00:00/40 tag 22 ncq 65536 in
Apr 24 14:09:22 python kernel: [  354.761011]          res 40/00:00:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
Apr 24 14:09:22 python kernel: [  354.761015] ata7.00: status: { DRDY }
Apr 24 14:09:22 python kernel: [  354.761019] ata7.00: failed command: WRITE FPDMA QUEUED

Der Rechner hat sich dann gelegentlich ganz weghängt (keine Platten mehr verfügbar).

verschiedene Doku im Internet besagt, daß die SSD Platte "lügt" und gar kein NCQ (native command queing) unterstützt. Ich habe in /etc/rc.local die Anweisung echo "1" > /sys/block/sda/device/queue_depth aufgenommen um kein Command Queueing auf der SSD mehr zu machen. Das Problem wurde dadurch zwar besser, aber nicht gelöst. Es kam dann z.B. zu folgendem Fehler.

Apr 25 21:36:45 python kernel: [   19.995680] isci 0000:05:00.0: isci_task_abort_task: abort task not needed for ffff88041a0d3000
Apr 25 21:36:45 python kernel: [   19.995683] isci 0000:05:00.0: isci_task_abort_task: Done; dev =           (null), task = ffff88041a0d3000 , old_request ==           (null)
Apr 25 21:36:45 python kernel: [   19.995684] sas: sas_scsi_find_task: task 0xffff88041a0d3000 is done
Apr 25 21:36:45 python kernel: [   19.995685] sas: sas_eh_handle_sas_errors: task 0xffff88041a0d3000 is done
Apr 25 21:36:45 python kernel: [   19.995688] sas: ata7: end_device-6:0: cmd error handler
Apr 25 21:36:45 python kernel: [   19.995699] sas: ata7: end_device-6:0: dev error handler
Apr 25 21:36:45 python kernel: [   19.995703] sas: ata8: end_device-6:1: dev error handler
Apr 25 21:36:45 python kernel: [   19.995706] ata7.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Apr 25 21:36:45 python kernel: [   19.995708] ata7.00: failed command: READ DMA
Apr 25 21:36:45 python kernel: [   19.995711] ata7.00: cmd c8/00:70:78:a0:c9/00:00:00:00:00/e6 tag 17 dma 57344 in
Apr 25 21:36:45 python kernel: [   19.995711]          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Apr 25 21:36:45 python kernel: [   19.995713] ata7.00: status: { DRDY }
Apr 25 21:36:45 python kernel: [   19.995715] ata7: hard resetting link

Ursache sind offensichtlich CRC Fehler bei der SATA Datenübertragung. Im SMART der SSD konnte ich mit smartctl folgendes auslesen:

SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
  9 Power_On_Hours          0x0032   099   099   000    Old_age   Always       -       1201
 12 Power_Cycle_Count       0x0032   099   099   000    Old_age   Always       -       908
[...]
199 CRC_Error_Count         0x003e   099   099   000    Old_age   Always       -       17
[...]

Jedes Mal wenn eine der obigen Meldungen im Log erschien, wurde der "199" "CRC_Error_Count" um eins erhöht. Viele Doku im Internet empfiehlt das Kabel zu tauschen, welches aber zuvor prima funktioniert hat. Ich habe die SSD einfach an den weißen onboard SATA Port (Das CD-ROM hängt dann an dem anderen) angeschlossen und seitdem funktioniert sie einwandfrei. Ich vermute daß die unterschiedlichen Signalpegel von SAS und SATA hier evtl. am Controller Schwierigkeiten machen. Der Linux-Treiber "isci" kennt auch Optionen um manuell die Kabellänge ("kurz, mittel, lang") zu setzen, das habe ich aber dann gar nicht mehr probiert. Die 1,5 TB SATA Festplatte macht am SAS Port keine Schwierigkeiten.